Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000052_owner-urn-ietf _Thu Oct 17 12:24:40 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03604 for urn-ietf-out; Thu, 17 Oct 1996 12:24:40 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03597 for <[e-mail]>; Thu, 17 Oct 1996 12:24:05 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA25994  (mail destined for [e-mail]); Thu, 17 Oct 96 12:24:00 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA17262; Thu, 17 Oct 1996 10:23:46 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 17 Oct 1996 10:31:13 -0600
To: Larry Masinter <[e-mail]>, [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] a possible security architecture for URNs
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Larry Masinter (at least at 02:21 AM 10/17/96 PDT)

>[...] the best we get from NAPTR is
>a hand-wave and protests that security isn't important because it
>might be expensive to implement.

That misrepresents my position on security.
But before I can boil down my position to a single statement,
let me establish some background.

Security is not a binary
property of a system. There is no such thing as a "secure"
system or a "non-secure" system. Systems can be secured
against particular forms of attack. That does not make those
attacks impossible, it makes them more difficult and expensive
to mount, lowers their probability of success, increases the
probability of detection and response, etc. Systems cannot be
made invulnerable to all possible forms of attack. Furthermore,
each threat that must be countered raises the cost of constructing
and operating the system. There is no point in spending more on
securing the system than the value of the information in the system,
the profit that can be derived from its operation, etc.

The forms of attack that might be mounted, the resources available
to an attacker, the costs of the measures required to defend
against them, *and the decision on whether or not to implement those
measures* cannot be evaluated in general. The likely threats and
countermeasures to employ will depend on the information in the system
and the resources available to the publisher of that information. *We
cannot make that decision for them*.

Of course, all these caveats are too tedious to mention in normal
conversation, so we tend to say things like "secure system" when
we really mean "a system that is hard to subvert using some common
attacks, but still not too expensive to operate".

With that background established, I can now state my position on
URN security as:

          We shouldn't define an all-encompassing
          security policy for URNs.

Not only does this mean that we should not establish a policy that
requires everyone to implement defenses against many forms of
attack, it also means that we should not prevent people from
implementing those defenses. I will object to any standards-track
proposal for a URN resolution proposal that does not provide the tools
to allow people to implement defenses against common attacks. Not
"all known tools" or "all possible attacks", but what in my best
technical judgement are basic tools against common attacks. I am not
a security expert, just an informed layman, so my technical judgement
in such cases will rely on people who are expert in the area. This means
people from the security area of the IETF, and some of my co-workers.


As far as the NAPTR proposal goes, those tools come from DNSSEC.
This toolkit does not include arbitrary encryption, but it
does include key management, signatures, and some authentication.
Arbitrary encryption would be nice, but it is unexportable. It
appears to be the rough consensus of the DNSSEC-WG that the tools
in the DNSSEC proposal are as much as can be provided at this time.

How do those tools affect the NAPTR proposal? The NAPTR resource
records themselves will, in all but the most unusual cases, be
things like:
   If the URI you are trying to resolve contains "foo", ask
   server "bar" how to procede.
or just
   ask server "baz", and talk to them using protocol X, Y, or Z.

Although it is possible that such information could be highly
confidential, it is not likely. Therefore the lack of arbitrary
encyption does not, in my best techincal opinion, greatly concern me.
Other attacks, such as spoofing responses, seem much more likely.
However, those are precisely the attacks that DNSSEC counters.

Once it comes time to talk with the resolver and actually put
the URN onto the wire (it has not left the client up to this
point) then we are no longer using DNS, we will be using one
of the "resolution protocols" such as HTTP, HDL, RWHOIS, RCDS, etc.
The security capabilities of these protocols are outside the
bounds of the NAPTR proposal, but I will note that allowing
the resolver to use different protocols allows the publisher
to pick one suited to their security needs.


Finally, note that the NAPTR proposal is targeted for an Experimental
RFC, not a proposed standard. Using it, along with the capabilities
of DNSSEC, allows those who care to gain experience with operating
"secure" resolvers. That experience can then be used when it comes
time to evaluate the security tools provided by standards-track
URN resolution proposals.


Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"